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IP-Based Conference Call Service for Circuit-Switched Networks 

FIELD OF THE INVENTION 



The present invention relates to a method, server device, terminal device and 
5 computer program product for enabling a provision of an Internet Protocol (IP) 
based conference call service, offered e.g. in an IMS (IP Multimedia Subsystem) 
network, to a circuit-switched (CS) network, such as a GSM network. 

BACKGROUND OF THE INVENTION 

In order to achieve access independence and to maintain a smooth interoperation 
10 with wired terminals across the Internet, an IP multimedia subsystem (IMS) core 
network as specified e.g. in the 3GPP (Third Generation Partnership Project) 
specification TS 23.228 has been developed to be conformant to IETF (Internet 
Engineering Task Force) "Internet Standards". The IMS enables network operators 
of mobile or cellular networks to offer their subscribers multimedia services based 
15 on and built upon Internet applications, services and protocols. The intention is to 
develop such services by mobile network operators and other third party suppliers 
including those in the Internet space using the mechanisms provided by the Inter- 
net and the IMS. The IMS thus enables conversion of, and access to, voice, video, 
messaging, data and web-based technologies for wireless users, and combines 
20 the growth of the Internet with the growth in mobile communications. In IMS, the 
Session Initiation Protocol (SIP) is used as the main session control protocol be- 
tween end user equipments and Call State Control Functions (CSCFs) located in 
the IMS. SIP enables network operators to provide new features for end users 
such as dialing with the use of SIP Uniform Resource Indicators (SIP URIs). 

25 IETF and 3GPP are working on a SIP conferencing service. The goal is to define 
how conferencing type of service can be established between 3GPP compliant 
SIP terminals. Simultaneously with this work, it is also studied how the interwork- 
ing between 3GPP IMS and legacy circuit-switched (CS) core network domains 
can be achieved. A cellular network, i.e. a Public Land Mobile Network (PLMN) 

30 can be regarded as an extension of networks with CS domains and packet 

switched (PS) domains within a common numbering plan and a common routing 
plan. The PLMN infrastructure is logically divided into a core network (CN) and an 
access network (AN) infrastructure, while the CN infrastructure is logically divided 
into a CS domain, a PS domain and an IMS. The CS and PS domains differ by the 



-2- 



way they support user traffic. These two domains are overlapping, i.e. they contain 
some common entities. A PLMN can implement only one domain or both domains. 
In particular, the CS domain refers to the set of all CN entities offering CS type of 
connections for user traffic as well as all the entities supporting the related signal- 
5 ing. A CS type of connection is a connection for which dedicated network re- 
sources are allocated at the connection establishment and released at the connec- 
tion release. The PS domain refers to the set of all CN entities offering PS type of 
connections for user traffic as well as all the entities supporting the related signal- 
ing. A PS type of connection transports the user information using autonomous 
10 concatenation of bits called packets, wherein each packet can be routed inde- 
pendently from the previous one. the IMS domain comprises all CN elements for 
provision of IP multimedia services comprising audio, video, text, chat, etc. and a 
combination of them delivered over the PS domain. 

So far, conferencing has been considered from IMS point of view where simulta- 
15 neously communicating parties are IMS subscribers with IMS subscription. This 
scope enables the full end to end use of SIP between the participants. SIP is an 
application-layer control protocol for creating, modifying and terminating sessions 
with one or more participants. These sessions include Internet multimedia confer- 
ences, Internet telephone calls and multimedia distribution. In SIP-based confer- 
20 encing, a conference-URI (Uniform Resource Indicator), e.g.: 



SIP: conf_234@conference.operator.com 

is used to establish a conference. A drawback of this solution is that it is com- 
pletely based on IP and thus cannot be used with GSM technology. 

The 3GPP Release 6 standard will introduce interworking between the IMS and 
25 the CS domain. 3GPP will however only specify procedures to have speech calls 
placed between the CS domain and IMS. Interworking is provided with introduction 
of Media Gateway Control Function (MGCF) and IMS-Media Gateway (IMS- 
MGW). Interworking of other type of calls such as video telephony are currently 
out of scope. 

30 

The 3GPP Release 5 standard specifies a limited set of services, like call forward- 
ing, call line identification, etc. 3GPP Release 6 will introduce more services, con- 
ference call being one of them. Conference call is currently under standardization 
in IETF, and the 3GPP will adopt the service from there to its own standards. 
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The Release 6 conference call service will bring several benefits compared to the 
existing service e.g. in GSM network. In order to provide similar features in CS 
mobile networks, enhancements to the existing GSM service are needed. In par- 
5 ticular, the conventional GSM conference call service lacks many of the features 
that have been planned in the All-IP conference framework. These features can be 
seen as requirements that the enhanced service must fulfill and cover easy and 
fast creation of the conference call from mobile terminal, while each participant 
has to know whether she/he has been added to the conference, who else is in the 
1 0 same conference, if others join the conference, if others leave the conference dur- 
ing the session, for how long the conference session has been running, or when 
others have been joined. 

In GSM, the user needs to call the members and add them to the conference one- 

15 by-one. This obviously takes time if the group is large. Furthermore, the creator of 
the conference needs to set up a private call to the new participant, while the con- 
ference session is on hold. In this private call the creator usually tells the partici- 
pant that he/she is being added to a conference. GSM does not provide an auto- 
matic mechanism to share this information. Usually the creator introduces all parti- 

20 cipants to each other, and tells to others that he/she is adding a new participant to 
the conference. The participant who is leaving tells it before doing so. A resulting 
problem is that the call might be dropped accidentally or by network or radio link 
failure. In these cases it might take a long time before the other participants realize 
this. The only way for a participant to know how long the session has been running 

25 or when other have been joined is to ask it from the creator or certain participants. 
Furthermore, the only way to moderate the conference is to tell orders in the voice 
channel. The only way to know who has a right to speak is to listen to the orders 
the moderator is telling. GSM does not provide an automatic mechanism to share 
the above mentioned different kinds of information. Furthermore, voice channels 

30 are used inefficiently since there is no central point in the network to mix the voice 
channels. 

Moreover, if the conference creator drops out, the whole conference will be lost. In 
addition, the maximum number of participants in the GSM conference call, i.e. 
35 multiparty call, is six. 
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SUMMARY OF THE INVENTION 

It is therefore an object of the present invention to enhance the existing second 
generation conference service to provide similar enhanced functionalities as being 
standardized at present in IETF/3GPP Release 6 for All-IP IMS networks. 

5 This object is achieved by a method for providing an IP-based conference call ser- 
vice to a circuit-switched network, said method comprising the steps of: 

— transmitting via a data path a conference request directed to an application 
server which provides said conference call service; 

10 — receiving via said data path a conference routing number for the requested 
conference call in response to said request; and 

— using said received conference routing number to set up a circuit-switched 
connection as a call leg of said conference call. 

15 Furthermore, the above object is achieved by a terminal device for providing an IP- 
based conference call service in a circuit-switched network, said terminal device 
comprising: 

— communication means for transmitting via a data path a conference request 
directed to an application server which provides said conference call service, 

20 and for extracting a conference routing number from a response received via 
said data path; and 

— establishing means for establishing a circuit-switched call using said extracted 
conference routing number. 

25 Additionally, the above object is achieved by a server device for providing an IP- 
based conference call service to a circuit-switched network, said server device 
comprising communicating means for receiving a conference request via a data 
path and for responding to said conference request with a response transmitted 
via said data path and including a conference routing number for said circuit- 

30 switched network. 



-5- 



Finally, the above object is achieved by a computer program product comprising 
code means adapted to produce the steps of the above method when loaded into 
the memory of a terminal device. 

Accordingly, a conferencing mechanism is provided by which existing 2nd genera- 
5 tion conference services are enhanced to provide similar functionalities as cur- 
rently being standardized in IETF/3GPP Release 6 for IP-based networks, e.g., 
All-IP IMS networks. Thus, users without VoiP (Voice over IP) capability may use 
IMS voice conferencing services, so that IMS-based voice conferencing is allowed 
before the availability of VoIP. 

10 According to the proposed solution, it is possible to implement many features al- 
ready now in CS mobile networks, without any need to wait for the deployment of 
All-IP networks. A conference routing number which can be used in the circuit- 
switched network to route separate call legs to the conference server is allocated 
and forwarded to the participants in the circuit-switched network. The user plane 

15 can then be mixed at a media gateway device. Modifications are therefore only 
required at conference-aware terminal devices and at the conference server. 
These changes can easily be implemented by corresponding changes of the con- 
trol applications running on these devices. No changes are required in the net- 
work, as routing can be done like in normal circuit-switched cases. 

20 Participants of the conference call can be selected and a corresponding informa- 
tion specifying the selected participants can be added to the conference request. 
Thereby, the participants are specified at the conference server and requesting 
callers can be checked if they are authorized to participate at the conference call. 

The transmitting step may be performed based on a pre-configured address infor- 
25 mation. This pre-configured address information may be set in a service subscrip- 
tion stage of a respective terminal device. This assures a quick and automatic 
setup of a conference call by a circuit-switched terminal. As an alternative, the ad- 
dress information may be obtained using a client configuration mechanism, which 
may be based for instance on SIP, DHCP, or means specifically designed for this 
30 use. 



The conference routing number may be an E.164 number. Thus, a normal tele- 
phone number is used instead of the conference-URI for routing the call towards 
the conference server. 
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Furthermore, a session-related information can be added to the request, wherein 
the session-related information may comprise at least one of a subject, a picture of 
the subject, and an importance of the conference session, to thereby inform the 
conference server about specific particularities of the requested conference call. In 
5 addition, information on payer of the conference or payer of the individual call legs 
can be added. Other conference session related information might be animation, 
video clip, sound clip, textual description, and the ,like. 

The data path can be any data transmission path, channel, bearer or session, 
which provides capability of transmission of the conference request to the applica- 

10 tion server. As an example, the conference request may be transmitted by using 
Short Message Service (SMS). As an alternative example, the conference request 
may be transmitted by using Unstructured Supplementary Service Data (USSD), 
Wireless Application Protocol (WAP), or Hyper Text Transfer Protocol (HTTP). As 
a further alternative example, the conference request may be transmitted by using 

15 a SIP (Session Initiation Protocol) message. In this case, at least one Session Ini- 
tiation Protocol and/or Service Description Protocol extension may be used for 
communicating CS specific information. 

Hence, an easy and fast way to request a conference call and receive a confer- 
ence routing number from the conference server is provided. The circuit-switched 
20 connection may be set up to a media gateway control device which may then route 
the circuit-switched call to the conference server. In particular, the media gateway 
control device may convert the conference routing number into an IP-based con- 
ference address. The routing number can be reserved at the conference server 
during the conference call. 

25 A request to join the conference call may be forwarded from the conference server 
to other participants specified in a conference request. In particular, the join re- 
quest may comprise at least one of an identification of the conference initiator, a 
subject of the conference session, and an information about a moderation of the 
conference session. By this request, participants are aware that the call is not a 

30 regular telephony call, but a conference session, and thus this request fulfills the 
initially mentioned specific information requirement that enhanced services should 
fulfill. Moreover, the information about other participants in the conference session 
fulfills the initially mentioned requirement that each participant should know who 
else is participating in the same conference. 
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If a participant shall be excluded from the conference call, a respective kick-out 
request may be forwarded by the conference server via the data path. This kick- 
out request may include an identification of the conference call and the participant 
to be excluded. Hence, also an easy and quick option to kick out participants with- 
5 out requiring excessive signaling or processing capacity is provided. 

The conference call may support at least one of an audio component, a non-real 
time video component, an application component and a chatting component. 

The connection set-up may be performed via the Mt interface using the Confer- 
ence Policy Control Protocol (CPCP). This provides the advantage that circuit- 
10 switched subscribers do not necessarily require IMS subscription, since the call 
does not have to be routed through the IMS to the conference server. Instead, a 
direct interface between the conference server and the media gateway control de- 
vice is provided. As an alternative, the connecton set-up may be performed using 
SIP if the circuit-switched subscriber has an IMS subscription. 

1 5 The communication means of the terminal device may be configured to use the 
respective data channel for forwarding the request. The communication means 
and the establishing means may be integrated in a conference call application or 
even a generic or normal native telephony application of the terminal device. This 
conference call application may be implemented as a native client application or 

20 as a MIDIet application. Thereby, easy enhancement of 2 nd generation terminal 
devices is possible to support the IP-based conference call service. 

The server device or conference server may comprise allocating means for allo- 
cating the conference routing number as a temporary E.164 number to the confer- 
ence call. In particular, a block of E.164 numbers for conference calls may be re- 
25 served by the allocating means. This reserved block of E.164 number may com- 
prise a sub-block of toll-free numbers and sub-block of charged numbers. In this 
case, the allocating means may be configured to select the E.164 number from the 
sub-blocks based on a charging information included in the conference request. 

Furthermore, the communicating means may be configured to send a conference 
30 routing number to other participants specified in the conference request. Checking 
means may be provided for checking whether callers of received calls relating to 
the conference call match with the other participants specified in the conference 
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request. Thereby, third persons who know or guess the E.164 conference number 
cannot join the conference. 

Additionally, connection control means may be provided in the server device for 
connecting together individual call legs of participants in a media gateway device. 
5 In this respect, interface means may be provided to establish a direct connection 
to a media gateway control device so as to enable routing of a set-up call for the 
conference call from the circuit-switched network to the conference server. 

Further advantageous modifications are defined in the dependent claims. 

BRIEF DESCRIPTIONS OF THE DRAWINGS 

10 In the following, the present invention will be described in greater detail on the ba- 
sis of preferred embodiments with reference to the accompanying drawings, in 
which: 

Fig. 1 shows a schematic block diagram of a network configuration according to 
the preferred embodiments; 

15 

Fig. 2 shows a conventional IETF conference architecture; 

Fig. 3 shows a more detailed block diagram of the network architecture for support 
of circuit-switched subscribers in an IP-based conference architecture, according 
20 to the first preferred embodiment; 

Fig. 4 shows a schematic diagram indicating signaling flows for initiating a new 
conference call according to the first preferred embodiment; 

25 Fig. 5 shows a schematic diagram indicating signaling flows for kick-out of a par- 
ticipant according to the first preferred embodiment, and 

Fig. 6 shows a schematic diagram indicating signaling flows for initiating a new 
conference call according to a second preferred embodiment. 



30 
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PESCRIPTION OF THE PREFERRED EMBODIMENTS 

The preferred embodiments wilt now be described on the basis of a SIP confer- 
encing functionality in an IMS network environment to which terminal devices of a 
CS network are connected. 

5 Fig. 1 shows a schematic block diagram of the network architecture according to 
the preferred embodiment, wherein mobile terminals MS-A 15 and MS-B 17 of a 
GSM (Global System for Mobil communication) network can be directly connected 
to an application server (APSE) 20 which provides a SIP conferencing functionality 
or conference service. The individual call legs L1, L2 to the mobile terminals 15, 

10 17 are combined or mixed in a media gateway function (MGW) 50. Further more, a 
Media Gateway Control Function (MGCF) 40 is provided for controlling the MGW 
50. In particular, the MGCF 40 is arranged to control those parts of a call state 
which pertain to connection control for media channels in the MGW 50. To achieve 
this, it communicates with Call Session Control Functions (CSCFs) of the IMS 

1 5 network, as defined in the 3GPP specification TS 23.228. The gateway functional- 
ity is achieved at the MGCF 40 by performing protocol conversion between the 
Integrated Services Digital Network User Part (ISUP) protocol and the IMS call 
control protocols. 

The MGW 50 is arranged to terminate bearer channels from the CS network, e.g. 
20 the GSM network, and media streams from the packet-switched (PS) network, e.g. 
the IMS network. The MGW 40 may support media conversion, bearer control and 
payload processing. It interacts with the MGCF 40 for resource control, owns and 
handles resources such as echo cancellers etc., and may comprise corresponding 
codec functions. 

25 According to the preferred embodiment, existing 2 nd generation conference ser- 
vices are enhanced to provide similar functionalities as in SIP conferencing for 
IMS networks. In particular, a conference E.164 number or any other conference 
routing number which can be used in the CS network environment are allocated to 
route the separate call legs L1 and L2 of the CS network environment to the con- 

30 ference server 20. The MGW 50 is then used to mix the bearers of the user plane. 
To achieve this, a special conference call application is provided in the confer- 
ence-aware mobile terminals 15, 17. This conference call application comprises a 
communication part 1 52 which uses a data channel dch to communicate with a 
corresponding communication part 202 of the conference server 20. The commu- 
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nication part 152, 172 communicates with a telephone application 154, 174 to initi- 
ate CS calls towards the conference server 20 via the MGCF 40. In the first pre- 
ferred embodiment, the Conference Policy Control Protocol (CPCP) as described 
in the IETF Internet Draft £ 'dmft~rosenberg'Sipping'Conference-fmmework-01.txt" 
5 can be used for communication via the Mt or Ut interface between the respective 
communication parts 152, 172 of the CS terminal devices 15, 17 and the commu- 
nication part of the conference server 20. 

Therefore, in the preferred embodiment, no changes are required in the network, 
but only in the terminal devices 15, 17 and the conference server 20, since the 
10 routing is preformed in the normal CS manner. This solution enables provision of 
IMS conference services to conventional CS users. 

In the following brief description of an establishment of a conference call, it is as- 
sumed that the terminal device MS-A 15 is the conference host which creates the 
conference. In this case, the communication part 152 of the mobile terminal MS-A 

15 15 creates a conference request based on a user selection of a participants e.g. 
from a phonebook application, and forwards the request via the data channel dch 
to the conference server 20. The communication part 202 of the conference server 
20 receives the conference request and controls an allocation part 204 to allocate 
a temporary conference E.164 number to the conference, e.g. +49 89 600 1234. 

20 This E.164 number is returned by the communication part 202 to the host terminal 
MS-A 15 of the conference. Moreover, the allocated E.164 number is also sent to 
the other requested participants as indicated in the conference request. 

In response to the receipt of the allocated conference E.164 number, the host ter- 
minal MS-A 15 and the other participants, e.g. the terminal MS-B 17, initiate a 
25 normal CS call to this E.164 number. These calls are then routed by the normal 
network routing function to the conference server 20 via the MGCF 40. It is to be 
noted here that the routing path may involve other CSCF nodes (e.g. I-CSCF or P- 
CSCF) of the IMS network which have been omitted here for reasons of simplicity. 

The conference server 20 receives all the calls and checks whether the callers are 
30 the same requested participants as indicated in the original conference request. 
This may be achieved by checking calling party numbers and compare these 
numbers to the numbers indicated in the conference request. Then, the confer- 
ence server 20 controls the MGCF 40 to connect the call legs of the participants 
together in the MGW 50 to establish the conference call. After the conference, the 

i 
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E.164 number is released by the allocation part 204 of the conference server 20 
and can be used again for another conferences. 

In particular, the allocation part 204 may reserve a block of E.164 numbers for 
conference calls. For example, this block may comprise 2000 numbers, e.g; +49 
5 89 600 1000 to +49 89 600 2999. These reserved numbers should be routable in 
normal telephone networks such as PSTN, GSM or other CS networks. The charg- 
ing of the conference call may be based on two charging possibilities, e.g., the 
conference host pays everything or everybody pays for its own call leg. To achieve 
this, the block of E.164 numbers can be divided into two sub-blocks, e.g., numbers 
10 +49 89 600 1000 to +49 89 600 1999 as toll-free numbers in the network where 
the conference host pays the conference, and numbers +49 89 600 2000 to +49 
89 600 2999 as normally charged numbers where each participant pays a normal 
tariff. Then, the conference host can indicate in the conference request who is go- 
ing to pay for the conference. 

1 5 The data channel dch may be a SMS channel to be used as an interface between 
the conference server 20 and all participants including the host terminal. Then at 
least the conference host needs the additional communication part 152, 172 which 
may be implemented by an additional software feature or application of the termi- 
nal to create the conference request to be sent to the conference server 20 using 

20 SMS or another suitable data channel. The conference server 20 sends the alio- , 
cated conference E.164 number in respective SMS messages to all participants. 
Thereby, no specific modifications are required in the terminals of the participants. 
A normal SMS message may be used, such as: 

"You have been invited to conference. Host: +49 175 123 4567. Call to number 
25 +49 89 600 1 100 to join the conference. The conference is free of charge." 

As an advanced alternative, ail participating terminals may have respective con- 
ference applications which make their user interface more comfortable. 

Fig. 2 shows an IETF conference framework as used in the conference server 20 
and specified in the above mentioned IETF Internet Draft. According to this con- 
30 ference architecture, SIP supports initiation, modification, and termination of media 
sessions between user agents. A user agent is defined as an interface between 
the user and a network application. It thus provides an interface to the user and 
sends and/or receives messages to the network. The central component in a SIP 
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conference is the focus 24 which is a SIP user agent addressed by a conference- 
URI and identifying a conference. The focus 24 maintains a SIP signaling relation- 
ship with each participant in the conference. The result is a star configuration. The 
focus 24 is responsible for making sure that the media streams which constitute 
5 the conference are available to the participants in the conference. It does this 
through the use of one or more mixers 26, each of which combines a number of 
input media streams to produce one or more output media streams. The focus 24 
uses a media policy to determine the proper configuration of the mixers 26. 

Furthermore, the focus 24 has access to a conference policy composed of mem- 
10 bership and media policies for each conference. Effectively the conference policy 
can be thought of as a database which describes the way that the conference 
should operate. It is the responsibility of the focus 24 to enforce those policies. 
The conference is represented by a conference-URI which identifies the focus 24. 
Each conference has a unique focus and a unique conference-URI identifying the 
1 5 focus. Requests to the conference-URI are routed to the focus 24 for that specific 
conference. In the IMS environment, a user or participant 10 usually joins the con- 
ference by sending a SIP INVITE request addressed to the conference-URI. As 
long as the conference policy allows, the INVITE request is accepted by the focus 
24 and the participating terminal 10 is brought into the conference. Users can 
20 leave the conference by sending a BYE request, as they would do in a normal call. 
Similarly, the focus 24 can terminate a dialogue with a participant, should the con- 
ference policy change to indicate that the participant is no longer allowed in the 
conference. 

The participant 10 can communicate with a conference policy function 29 of the 
25 conference server 20 by using the CPCP protocol. Through this protocol it can 

affect the conference policy. CPCP and the Media Policy Control Protocol (MPCP) 
are new protocols at the Mt reference point between the participant 10 and the 
conference server 20. The CPCP allows the participant 10 to manage the non- 
media part of the conference, e.g. membership and authorization, and the MPCP 
30 allows the participants 10 to manipulate the media in the conference by a corre- 
sponding media policy function 28. 

Furthermore, a conference notification function 22 is provided in the conference 
server 20, which acts as a notifier accepting subscription to the conference state, 
and notifying subscribers about changes to that state. The conference state in- 
35 eludes the state maintained by the focus 24 itself, the conference policy, and the 
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media policy. In the IMS network, the participant 10 may be any software element 
that connects a user to a conference. It implements, at minimum, a SIP user 
agent. 

Thus, as indicated in Fig. 2, the participant 10 interacts with the different functions 
5 of the conference server 20 to determine or get informed about the conference 
and media policy. It is noted that the protocol selections are still open in the IETF 
standard. For CPCP there are three candidates at the moment, i.e. SOAP, XML- 
RPC and ACAP. As to the MPCP, at least SOAP and XML-RPC have been pro- 
posed. 

10 Fig. 3 shows a 3GPP architecture for providing support of CS subscribers in SIP 
conferencing. The IETF framework can be mapped into the 3GPP Release 6 IMS 
architecture. In particular, the Mt reference point is needed to control conference 
and media. According to preferred embodiment, a subset of the MPCP and the 
CPCP are used. As a bearer for communication between the participant 10, which 

15 may be an application in a terminal device or user equipment (UE), and the con- 
ference server 20 via the Mt reference point, a data bearer such as SMS can be 
used in the first preferred embodiment. Thereby, direct communication between a 
participant, e.g. the mobile terminal MS-A 15, and the conference server 20 can be 
provided to set up a conference call even by a CS terminal device. Moreover, the 

20 media policy stored in a respective media policy database 281 and the conference 
policy stored in a respective conference policy database 291 can be controlled 
from the CS network side. 

Furthermore, an interface is provided between the MGCF 40 and the conference 
server 20. This interface is required for routing a call from the CS domain to the 

25 conference server via the MGCF 40. This interface can be a SIP ISC interface. As 
an alternative, the messages could also be routed through a Border Gateway Con- 
trol Function (BGCF) and a CSCF using an Mj, Mi, and/or ISC interface. In view of 
the fact that the CS subscriber does not necessarily have IMS subscription, it is 
not needed to route the call through the IMS network to the conference server 20. 

30 When the call has been received by the conference server 20, the respective call 
leg for the conference is established by the conference server 20 based on a cor- 
responding control signaling via the Mp interface to a MRFP (Media Resource 
Function Processor) 60 which acts as a mixer and which controls the MGW 50 via 
the Mb interface to provide the required media interworking. The MGW 50 is con- 

35 nected via a CS connection, e.g. a PSTN or a PLMN connection, to the participat- 
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ing mobile terminal 15. Hence, by providing the new interfaces between the con- 
ference server 20 and the MGCF 40 and the participant, respectively, the SIP con- 
ferencing service can also be used by CS subscribers or terminals. Since the con- 
ference server 20 and the MGCF 40 may belong to the same operator network, 
5 the interface between these elements can also be implemented as a proprietary 
interface, or functionalities of the conference server 20 and the MGCF 40 can be 
integrated/implemented in the same network element. 

In the following, a more detailed description of the signaling flows required for es- 
tablishing a conference call and kicking out or excluding a participant, according to 
10 the preferred embodiment, is described with reference to figures 4 and 5. 

Fig. 4 shows a signaling flow for a conference creation by a user of the terminal 
MS-A 15. For simplicity reasons, a conference call between two participants is 
shown. However, more participants can be added and the principles described 
herein remain the same. 

15 According to the above IETF Internet Draft, the IETF defines two types of confer- 
ence participants, i.e., a conference-unaware and a conference-aware participant. 
Conference-unaware participants are not aware that they take part in a confer- 
ence. The corresponding terminal device or UE views the session as a basic call 
session. A participant can join the conference by dialing a number and can be in- 

20 vited to a conference, but the participant has no means to control the conference, 
e.g. add more participants. Only conference-aware participants can control the 
conference. The procedure according to the preferred embodiment allows a 2 nd 
generation CS subscriber to become a conference-aware participant of an IMS 
conference. In conventional systems, CS subscribers only can be conference- 

25 unaware participants in IMS. 

According to Fig. 4, the host terminal MS-A 15 initiates a conference call request 
to the conference server (APSE) 20. The address of the conference application in 
the conference server 20 has been pre-configured to the terminal, e.g. in a service 
subscription stage. In the preferred embodiment, this address remains the same 
30 for all conference sessions created in this conference server 20. Of course, an 
option may be provided to change this pre-configured address based on a net- 
work-originated signaling to the mobile terminal MS-A 15. 
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The conference request is generated by the communication part 1 52 of the host 
terminal MS-A 15 and contains a list of members who should be called to the ses- 
sion. Hence, this conference request can be seen as a mass invitation operation in 
CPCP. By this operation, the initially mentioned requirement of easy and fast crea- 
5 tion of conference calls from mobile terminals is fulfilled. It is also possible to cre- 
ate a conference first, i.e. reserve the conference E.164 number, and then start to 
invite the participants one-by-one, wherein however the benefit of fast and easy 
set-up with mass invitation is not achieved to the same extent. 

The host terminal MS-A 15 may send additional session-related information to- 
10 gether with the invitation or conference request. Such session-related information 
may define details such as the subject of the session, a picture that illustrates the 
subject, importance of the session, etc. 

The conference server 20 contains the focus 24, conference policy function 29, 
media policy function 28, and conference notification function 22. 

15 As already mentioned, the bearer for the direct connection between the CS host 
terminal MS-A 15 and the conference server 20 can be any data channel to define 
the Mt reference point, e.g. SMS, USSD, or WAP or HTTP over GPRS, etc. 

The above described forwarding of the conference request to the conference 
server 20 is indicated by step 1 in Fig. 1. 

20 In step 2, the allocation part 204 of the conference application in the conference 
server 20 arranges a dynamic E.164 routing number that routes the call to the con- 
ference server 20 in the home network (HPLMN) of the service provider. The rout- 
ing number is kept reserved for the duration of the session. After the session has 
been finished, the routing number can be re-allocated. Hence, this dynamic E.164 

25 number presents the conference-URI as specified in the above IETF Internet Draft 
in the CS domain. The number is unique and identifies the focus 24, which is re- 
sponsible for this conference session. This conference routing number is returned 
to the host terminal MS-A 15 in a response message forwarded via the data chan- 
nel. 

30 In step 3, the host terminal MS-A initiates a CS call to the received conference 
routing number. This call is routed in step 4 via a visitor mobile switching center 
(VMSC) 70 of the visited network VPLMN-A of the host terminal MS-A 15 and via 
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the MGCF 40 to the conference server 20. In particular, in step 5, the MGCF 40 
sends a SIP INVITE request to the conference server 20. The INVITE request con- 
tains a local descriptor of the media resource. Furthermore, the MGCF 40 converts 
the E.164 number to a Telephone Uniform Resource Locator (Tel URL), which 
5 corresponds to the conference-URI that identifies the focus 24 in the conference 
server 20. In step 6, the conference server 20 reserves the media resources from 
the conference media mixer in the MGW 50. The descriptor of the reserved media 
resources is then sent back to the MGCF 40 in a SIP 200 response. In step 7, the 
MGCF 40 modifies the resources in the MRFP 60 and updates the remote media 
10 descriptor to the context. Then, the MGCF 40 sends an ISUP answer message 
ANM via the CS connection to the VMSC 70. In step 8, the host terminal MS-A 15 
receives a CONNECT message from the VMSC 70 and the media path is con- 
nected two-way between the user or host terminal MS-A 15 and the conference 
media mixer at the MRFP 60 via the media interworking function at the MGW 50. 

15 Then, in step 9, the conference server 20 sends a request to join to the conference 
to other indicated participants, e.g. the other terminal MS-B 17 of the CS network 
via the data channel. This join request contains the routing number, information 
about other participants currently in the session, and details of the conference, 
such as who is the initiator, when was the conference initiated, subject of the ses- 

20 sion, is the session moderated, etc. By this join request, each of the other partici- 
pants is aware that the call is not a regular telephony call, but a conference ses- 
sion, and thus the join request fulfills the initially mentioned requirement that each 
participant should know that he or she has been added to the conference. Fur- 
thermore, the join request contains information about other participants in the ses- 

25 sion to thereby also fulfill the initially mentioned requirement that each participant 
should know who else is participating in the same conference. 

In practice, all participants are requested to join simultaneously, even the creator 
or host of the conference, i.e. the host terminal MS-A 15. This ensures that the 
session is setup as fast as possible. The join request is also sent via the data 
30 channel, e.g. SMS, USSD, WAP or HTTP. 

In step 10, the other participant MS-B 17 accepts the join request. At this point, the 
conference notification function 22 of the conference server 20 can notify the other 
participants, e.g. the host terminal MS-A 15, that a new participant has accepted to 
join the conference session. Similarly, if one participant rejects the request, the 
35 other participants are notified. 
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In step 1 1 , the other participating terminal MS-B 17 makes a call to the received 
conference routing number. This CS call is routed via another VMSC 72 of the 
other visitor network VPLMN-B of the other participating terminal MS-B 17 to the 
MGCF 40. In step 12, the call is routed as an ISUP initial address message (IAM) 
5 to the MGCF 40. In response thereto, the MGCF 40 reserves the media resources 
at the MGW 50. Then, in step 13, the MGCF 40 sends a SIP INVITE request to the 
conference server 20. In response thereto, the conference server 20 reserves in 
step 14 the resources from the MRFP 60 and adds the media streams together in 
this conference mixer. The conference server 20 sends notifications to the other 
10 participants that a new participant has joined the conference. Thereby, the initially 
mentioned requirement that each participant has to know if others join the confer- 
ence is fulfilled. 

In step 15, the MGCF 40 modifies the resources in the MGW 50 and updates the 
remote media descriptor to the context. Then, the MGCF 40 sends an ISUP ANM 

1 5 message to the second VMSC 72 of the other participant in step 1 6. The terminal 
device MS-B 17 of the other participant receives a CONNECT message from the 
VMSC 72 in step 17 and the media path is connected two-way between the user 
and the mixer. Thereby, a conference call between the CS terminals MS-A 15 and 
MS-B 17 is established via the ISM conference server 20, such that IMS services 

20 can be provided to the conventional CS terminals MS-A 15 and MS-B 17. 

Fig. 5 shows a diagram similar to Fig. 4, wherein however signaling flows for a 
kick-out procedure of a participant are shown. 

In step 1 , the host terminal MS-A 15 sends a request to kick-out the other partici- 
pant MS-B 17 from the conference session. This kick-out request contains the 
25 identification (ID) of the MS-B 17 and of the conference session. Also this kick-out 
request is forwarded via the data channel. However, it should be noted that the 
kick-out request is not limited to the session creator or host. The conference policy 
and more detailed the membership policy may describe specific roles in the con- 
ference session, in particular who is allowed to request certain roles. 

30 In step 2, the conference server 20 acknowledges the receipt of the kick-out re- 
quest. Then, in step 3, the conference server 20 sends a SIP BYE request towards 
the other participant MS-B 17 via the MGCF 40, which is acknowledged by the 
MGCF 40 in step 4. In step 5, the MGCF 40 sends a ISUP RELEASE request to 
the second VMSC 72 which acknowledges the request in step 6. In step 7, the 
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second VMSC 72 sends the RELEASE request to the other participant MS-B 17. 
The other participant MS-B 1 7 acknowledges this request in step 8 by a REL 
COMPLETE response. Finally, in step, 9 the conference server 20 sends a notifi- 
cation to all participants that one participant has left the conference. This fulfills the 
5 initial requirement that each participant should know if others leave the conference 
during the session. 

Thereby, an enhanced kick-out service can be provided to conventional CS termi- 
nals. It is noted that CPCP also enables a kick-out request for multiple participants 
at once, which is called a mass ejection. 

10 As already mentioned, to provide the above enhanced conference service to con- 
ventional CS terminals, a special conference call application is required in the con- 
ference-aware terminals MS-A 15 and MS-B 17. This application comprises the 
communication part 152, 172 which uses the data channel to communicate with 
the conference server 20 and which communicates with the telephony application 

15 154, 174 to initiate CS calls towards the conference server 20. One way to imple- 
ment this conference call application is to provide a native client that integrates 
smoothly to the existing terminal functionalities like contacts, e.g. phonebook, and 
telephony application 154. 

Another option is to use a Ml Diet technology for the implementation of the confer- 
20 ence call application. A MIDIet is a mobile information device application. In par- 
ticular, MIDIets are JAVA applications that run on mobile terminals or other de- 
vices compliant with the reduced JAVA version called J2ME. A MIDIet with support 
of Personal Information Management (PIM) Application Programming Interface 
(API) can access to the contacts and read the conference participant's names and 
25 numbers from there. The corresponding protocol MIDP 2.0 allows the MIDIet to 
initiate a call to the conference server 20. The MIDIet can easily print the shared 
information, such as session subject, icon, etc., to the screen of the terminal de- 
vice. PIM API allows to store the shared participant's details, e.g. in vCards, in the 
phone book. A MIDIet with support of wireless messaging (WMA) API can send 
30 and receive SMS messages. The MIDIet can be even initialized by an SMS recep- 
tion. 



As already mentioned, many options are given for the bearer of the data channel. 
USSD is fast and reliable but is not widely deployed in networks. In contrast 
thereto, SMS is supported in every GSM network, but is a store and forward type 
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of service and thus might require more transmission time which might be disad- 
vantageous for real-time communications. Furthermore, SMS messages are lim- 
ited in size to 160 characters per message. WAP over GPRS is fast, but opening 
the GPRS session might take too long for real-time communication. Moreover, 
5 GPRS roaming is not yet widely supported. In this respect, it also has to be con- 
sidered that sending of a WAP push request utilizes SMS messaging and thus has 
the same disadvantage regarding slowness. However, as the size of the packet 
data units (PDUs) in the data channel is quite small, SMS is a viable option for the 
data bearer. The store and forward problem can be prevented by bypassing the 
10 serving mobile switching center (SMSC). Nevertheless, it is to be noted that any of 
the above data bearer options can be used as a feasible option for the implemen- 
tation of the present invention. 

Acording to a second preferred embodiment, the CS terminals 15, 17 are adapted 
to use SIP (Session Initiation Protocol) to control conference services. This would 

15 be the case e.g. when the mobile terminal MS-A 15 has subscribed to the IMS, but 
for some reason cannot use Voice over IP (VoIP) for voice calls, e.g., because 
Release 5 IMS is used or the mobile terminal MS-A 15 is roaming in the CS net- 
work. In this case, the mobile terminal MS-A 15 may send a SIP INVITE request to 
the conference server 20 using the data channel or data connection dch and in 

20 response it receives the conference number to be used in the CS network side. 
Now, the mobile terminal MS-A can start inviting other participants by sending a 
bunch of SIP REFER requests to the conference server 20, each indicating one 
terminal device to which the conference invitation should be sent. The actual me- 
dia session is however the CS call. 

25 

In the second preferred embodiment, SIP/SDP (Session Description Protocol) 
extension are used to carry CS specific information from the mobile CS terminal 
MS-A 15 to the conference server 20. This CS specific information may include an 
Indication from mobile terminal that a CS call or connection is needed. The con- 
30 ference routing or phone number is then carried in the response. In particular, the 
conference server 20 allocates the conference phone number, e.g. an E.164 num- 
ber, from the predefined range of numbers and returns it, e.g. as a tel URI, to the 
mobile terminal MS-A 15. 
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The mobile terminal MS-A 15 uses the conference number to initiate the CS call 
and invites other participants, e.g., by sending REFER requests if the other par- 
ticipants are registered to IMS. If the host terminal MS-A 15 does not know 
whether the invited terminal MS-B 17 is a SIP-capable CS user, the SDP exten- 
5 sion in an INVITE request from the application server 20 to other MS-B may carry 
a proprietary "CS-capability M extension, which would be accepted by the other ter- 
minal MS-B 15 if it is CS-capable. Thereby, the host terminal MS-A 15 can be in- 
formed about the SIP capability of the other terminal MS-B 17. 

10 The CS bearer and the SIP dialog are tied together in the conference server 20 
which is adapted to handle and synchronize actually two SIP dialogs that both are 
related to the CS session of the host terminal MS-A 15. A dynamic routing number 
pool and allocation can be arranged. The conference URIs can be created dy- 
namically, while the routing of dynamically created (service) URIs can be handled 

15 in IMS Release 6. Roaming can be based on IMS or GPRS. The P-CSCF can be 
located also in the home network. Signaling can be based on the 3GPP specifica- 
tion TR 29.847 v 0.1.0 and IETF draft "draft-johnston-sipping-cc-conferencing-01 w . 

The conference server 20 is adapted to handle CS-specific SDP/SIP extensions, 
20 e.g. proprietary SDP extensions, and/or to combine and/or synchronize two SIP 
dialogs concerning the same media session. Also, the mobile terminals are 
adapted to handle CS-specific SIP/SDP, and to handle the SIP dialog and corre- 
sponding CS bearer. In particular, DTM or WCDMA Multi-RAB may be needed. 

25 The MGCF 40 and the conference server 20 may communicate through the 
ISC/SIP interface or through already existing Mi, Mj and ISC interfaces. 

Fig. 6 shows a schematic diagram indicating signaling flows for initiating a new 
conference call according to the second preferred embodiment. 

30 

In steps 1 to 3, the host terminal MS-A 15 sends an INVITE request via a P-CSCF 
80 and an S-CSCF 90 of the IMS to the conference server 20. The required ad- 
dress of the conference server 20, e.g. Conference Factory URL, can be pre- 
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configured to the host terminal MS-A 15 or fetched using some standard mecha- 
nism. SDP may contain the offered medias. The host terminal MS-A 15 might re- 
quest media for voice and also e.g. for a unidirectional video stream which is car- 
ried in the PS domain. The SDP may contain a special information that the bearer 
5 for audio will be allocated from the CS domain. 

In steps 4 to 7, the conference server 20 reserves conference resources for the 
SWIS media from the bridge. Voice resources are not reserved at this point. The 
conference server 20 sends a SIP 183 response back to the host terminal MS-A 
10 15. The P-CSCF 80 authorizes the committed QoS for SWIS. The Contact header 
of the 183 response contains a temporary conference URL. This URL is a TelURL 
and E.164 number in order to reserve the bearer for voice from the CS domain. 

In steps 8 to 10, the host terminal MS-A 15 sends a GSM Setup request towards 
1 5 the received conference number. The number leads to the conference server 20 in 
the home network. The MGCF 40 reserves media resources from IMS-MGW 50 
and sends an INVITE request to conference server 20. The SDP in the INVITE 
request may contain a list of audio codecs supported by the IMS-MGW 50. The 
conference server 20 needs to be able to assign the new SIP session to the old 
20 session based on the conference number. 

Then, in steps 11 to 14, the conference server 20 modifies the resources in the 
bridge to contain the correct audio codecs and the remote IP address. The de- 
scriptor of the reserved media resources is sent back to the MGCF 40. Note that 
25 usually SIP 183 Session Progress is used for this purpose, the flow is simplified in 
Fig. 6. User plane for voice has been connected then. 

Any required SIP PRACK and UPDATE requests are not shown in Fig. 6. 

30 Finally, in steps 15 to 17, after the conference server 20 has received an UPDATE 
request and modified the resource reservations accordingly, it sends a final SIP 
response 200 OK for the INVITE request. The Contact header contains the con- 
ference URL, which is a Tel URL and E.164 number. This number is later on used 
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to identify this particular conference session. Furthermore, the Contact header 
may also contain a isfocus parameter to indicate that the address is for a confer- 
ence call. 

5 For subscription, the mobile terminal MS-A 1 5 may subscribe the state of the con- 
ference session. To achieve this, a SIP SUBSCRIBE request is sent to the Con- 
ference URL. If the conference server 20 accepts the subscription, it sends the 
current state of the conference session. This state is XML-coded inside a SIP 
NOTIFY message. The mobile terminal MS-A 15 acknowledges the received 

1 0 NOTIFY message. After this, the conference server 20 always sends a NOTIFY 
message to the subscribed mobile terminal MS-A 15 when the state of the confer- 
ence changes. 

A new member can be added to the conference by sending a SIP REFER request 
1 5 to the conference server 20. The request URL contains the conference URL. The 
Refer-To header contains the SIP URL of invited user, e.g. the mobile terminal 
MS-B 17. The Method parameter in the Refer-to header contains the value "Invite ". 
If the conference server 20 accepts the request, it notifies the requesting terminal 
MS-A 15 that the session towards the invited terminal MS-B 17 is in Trying state. 
20 Then, the conference server 20 reserves the media resources from the MRFP 60 
for other medias except audio, and sends a SIP INVITE request to the invited ter- 
minal MS-B 17. The INVITE request may contain an isfocus parameter in the Con- 
tact header that tells to the invited terminal MS-B 17 that the call is a conference 
call. The Contact header contains the conference URL which is a Tel URL and 
25 E.164 number. The INVITE request can contain also other information related to 
the session, e.g. subject, icon, importance, etc., which can be stored in the confer- 
ence server 20 or sent in each REFER request. The user B of the invited terminal 
MS-B 1 7 is now able to accept or reject the conference call request. 

30 If the user B accepts the call, the invited terminal MS-B 17 sends a SIP 183 re- 
sponse to the application server 20. The SIP 183 response may contain the media 
supported by the invited terminal MS-B 17. The conference server 20 modifies the 
codecs and the remote IP address in the MGCF 40 for other media except audio. 
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Then, the invited terminal MS-B 17 initiates a CS call towards the Conference 
number. The MGCF 40 reserves resources from the IMS-MGW 50. It sends a SIP 
INVITE request to the conference server 20, which contains the supported audio 
codecs and the local IP address in the MGW 50. In response thereto, the confer- 
5 ence server 20 modifies the resources in the MRFP 60 to contain the supported 
audio codec and the remote IP address in IMS-MGW 50. The conference server 
20 sends a SIP 200 OK response with the media information back to the MGCF 
40. Then, the invited terminal MS-B 17 receives a GSM CONNECT message. 

10 Once the conference server 20 receives the INVITE request from the MGCF 40, it 
needs to assign the SIP session to the original session that was initiated when the 
conference server 20 received the REFER request from the inviting terminal MS-A 
1 5. At the conference server 20, it may also be authorized that the invited terminal 
MS-B 1 7 is allowed to join to the conference. 

15 

Once the invited terminal MS-B 17 has received an UPDATE request from the 
conference server 20, it sends a SIP 200 OK response to the conference server 
20. The conference server 20 can modify the media resources in the MGCF 40 
according the SDP in the 200 OK response. At this point both audio and other me- 
20 dia (e.g. SWIS video) are connected with the other participants in the MRFP 60. 
Finally, the conference server 20 sends a NOTIFY request to the inviting terminal 
MS-A 15 that tells that the session to the invited terminal MS-B 17 is in confirmed 
state. 

25 After this the invited terminal MS-B 17 can subscribe the state of the conference 
as mentioned above. In the notification, the user B receives the current state of the 
conference, e.g. the list of other participants.Kick-out of a participant can be done 
in a similar manner, except that the REFER request contains value „BYE" in the 
method parameter of the Refer-to header. This causes the conference server 20 to 

30 send a BYE request to the member 

In a further alternative, a conference host, e.g. MS-A 15, can request another ter- 
minal device, e.g. MS-B 17, to join the conference by sending a REFER message 
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to the invited terminal device MS-B 17 instead of conference server 20. The 
REFER message then contains a conference address which can be either a con- 
ference URL or E.164 number. If the REFER message contains a conference 
E.164 number, the invited terminal device MS-B 17 establishes a circuit switched 
5 call leg towards the conference server 20 as described before. If the REFER mes- 
sage contains a conference URL instead, the invited terminal device MS-B 17 first 
sends an INVITE message to the conference server 20 using the received confer- 
ence URL. The conference server 20 then responds to the invited terminal device 
MS-B 17 with an allocated conference E.164 number, which the invited terminal 
10 device MS-B 17 can use to establish a circuit switched call leg towards the confer- 
ence server 20 as described before. 

Specifically, at the terminal side, the implementation of the present invention can 
be based on a software routine which can be directly downloaded or in any other 
1 5 way loaded as a kind of feature software to a program memory of the mobile ter- 
minal. Thereby, only little modifications are required for implementation. 

The present invention can be implemented in any network environment to provide 
an IP-based conference service to participants in conventional CS networks, as 

20 long as a data channel can be established between the participants and the re- 
spective enhanced IP-based conference server to signal a conference routing 
number to the participants which may then set-up a CS call towards the confer- 
ence server. As an alternative or additional option for both the first and the second 
embodiments, the call set-up procedure may be initiated by the conference server 

25 20. Then, the participants or CS terminals are merely informed by the received 

conference number that there is a call coming soon from that number and that it is 
a conference call. This server side initiation option may as well be used in combi- 
nation with the terminal side initiation option and both option s may be based on 
different kinds of commands. Moreover, the invention can be enhanced by adding 

30 support of other media components, like non-real time video over GPRS, applica- 
tion share, or chatting during conference session. The preferred embodiments 
may thus vary within the scope of the attached claims. 
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1 . A method for providing an IP-based conference call service to a circuit- 
switched network (10), said method comprising the steps of: 

a) transmitting via a data path a conference request directed to an applica- 
5 tion server (20) which provides said conference call service; 

b) receiving via said data path, a conference routing number for the re- 
quested conference call in response to said request; and 

c) using said received conference routing number to set up a circuit- 
switched connection as a call leg of said conference call. 

10 2. A method according to claim 1 , further comprising the step of selecting par- 
ticipants of said conference call and adding to said conference request an 
information specifying said selected participants. 

3. A method according to claim 1 or 2, wherein said transmitting step is per- 
formed based on a pre-configured address information. 

15 4. A method according to claim 3, further comprising the step of setting said 
pre-configured address information in a service subscription stage. 

5. A method according to any one of the preceding claims, wherein said con- 
ference routing number is an E. 164 number. 

6. A method according to any one of the preceding claims, further comprising 
20 the step of adding session-related information to said conference request, 

said session-related information comprising at least one of a subject, picture 
of the subject, payer of the conference, importance of the conference ses- 
sion, animation, video clip, sound clip, and textual description. 

7. . A method according to any one of the preceding claims, wherein said data 
25 path is a short message service channel. 



8. 



A method according to any one of claims 1 to 6, wherein said data path is a 
USSD, WAP, or HTTP channel. 
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9. A method according to any one of the preceding claims, wherein said 
transmission and/or reception steps are performed using Session Initiation 
Protocol. 

10. A method according to claim 9, wherein said transmission and/or reception 
5 steps are performed using at least one Session Initiation Protocol and/or 

Service Description Protocol extension for communicating CS specific in- 
formation. 

11. A method according to any one of the preceding claims, wherein said cir- 
cuit-switched connection is set up to a media gateway control device (40) 

10 which then routes the circuit-switched call to said application server (20). 

12. A method according to claim 1 1 , further comprising the step of converting 
said routing number into an IP-based conference address at said media 
gateway control device (40). 

13. A method according to any one of the preceding claims, further comprising 
1 5 the steps of reserving said routing number as a temporary conference rout- 
ing number at said application server (20) during establishment of said con- 
ference call and releasing said routing number for reuse after releasing said 
conference call. 

14. A method according to any one of the preceding claims, further comprising 
20 the step of forwarding via a data path a request to join said conference call 

from said application server (20) to other participants specified in said con- 
ference request. 



15. A method according to claims 14, wherein the forwarding step comprises 
transmitting said request using a SIP Invite message triggered by a re- 
25 ceived SIP Refer message. 



16. A method according to claim 14, wherein said join request comprises at 
least one of an identification of the conference initiator, a subject of said 
conference call, a price of the conference call leg, and an information about 
a moderation of said conference call, an animation, a video clip, a sound 
30 clip, and a textual description. 
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17. A method according to any one of claims 1 to 10 or claim 13, further 

comprising a step of forwarding via a data path said conference routing 
number from said application server (20) to at least one participant 
specified in said conference request to indicate that a conference call will 
5 be established from said conference number to said participant, wherein 

said at least one circuit-switched connection is set up from said application 
server (20) using said conference number as a calling party number via a 
media gateway control device (40) which then routes the circuit-switched 
call to a requested participant. 

10 18. A method according to any one of the preceding claims, further comprising 
the step of forwarding a kick-out request to said application server (20) via 
said data path to thereby have a participant excluded from said conference 
call. 

19. A method according to claim 18, wherein said kick-out request includes an 
15 identification of said conference call and an identification of at least one 

said participant to be excluded. 

20. A method according to any one of the preceding claims, wherein said con- 
ference call supports at least one of an audio component, a non-real time 
video component, an application component and a messaging component. 

20 21. A method according to any one of the preceding claims, wherein said con- 
nection set-up is performed by using a conference policy control protocol 
over an Mt interface as a data path. 

22. A method according to any of claims 1 to 14, further comprising the steps of 
forwarding via a data path a request to join said conference call from a re- 
25 questing participant to at least one participant specified in said conference 

request, wherein said request comprises said conference routing number 
and the connection setup step comprises setting up a circuit switched con- 
nection from at least one requested participant to application server (20) us- 
ing said conference routing number. 

30 23. A method according to claim 22, wherein the forwarding step comprises 

forwarding the request using SIP Refer message and the connection setup 
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step comprises establishing said at least one circuit switched connection 
using SIP Invite message. 

A terminal device for providing an IP-based conference call service in a cir- 
cuit-switched network, said terminal device (15, 17) comprising: 

a) communication means (152, 172) for transmitting via a data path a con- 
ference request directed to an application server (20) which provides 
said conference call service, and for extracting a conference routing 
number from a response received via said data path; and 

b) establishing means (154, 174) for establishing a circuit-switched call us- 
ing said extracted conference routing number. 

A terminal device according to claim 24, wherein said communication 
means (152, 172) is configured to use a short message service channel for 
forwarding said request. 

A terminal device according to claim 24, wherein said communication 
means (152, 172) is configured to use a SIP message for forwarding said 
request. 

A terminal device according to claim 26, wherein said communication 
means (152, 172) is configured to use at least one SIP and/or SDP exten- 
sion for communicating CS specific information. 

A terminal device according to any one of claims 24 to 27, wherein said 
communication means (152, 172) and said establishing means (154, 174) 
are integrated in a telephony application of said terminal device (15, 17). 

A terminal device according to any one of claims 24 to 28, wherein said 
conference call application is implemented as a native client application or 
as a Ml Diet application. 

A terminal device according to any one of claims 24 to 29, wherein said 
communication means (152, 172) are configured to transmit said confer- 
ence request in consequence of receiving first a request from another user. 
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31 . A server device for providing an IP-based conference call service to a cir- 
cuit-switched network, said server device comprising communicating means 
(202) for receiving a conference request via a data path and for responding 
to said conference request with a response transmitted via said data path 

5 and including a conference routing number for said circuit-switched net- 

work. 

32. A server device according to claim 31 , further comprising allocating means 
(204) for allocating said conference routing number as a temporary E.164 
number to said conference call. 

10 33. A server device according to claim 32, wherein said allocating means (204) 
is configured to reserve a block of E.164 numbers for conference calls. 

34. A server device according to claim 33, wherein said reserved block of E.164 
numbers comprises a sub-block of toll-free numbers and a sub-block of 
charged numbers. 

15 35. A server device according to claim 34, wherein said allocating means (204) 
is configured to select said E.164 number from said sub-blocks based on a 
charging information included in said conference request. 

36. A server device according to any one of claims 31 to 35, wherein said 
communication means (202) is configured to send said conference routing 

20 number via a respective data path to other participants specified in said 

conference request. 

37. A server device according to claim 36, further comprising checking means 
for checking whether callers of received calls relating to said conference 
call match with said other participants specified in said conference request. 

25 38. A server device according to any one of claims 31 to 37, further comprising 
connection control means for connecting together individual call legs of par- 
ticipants in a media gateway device (50). 

39. A server device according to any one of claims 31 to 38, further comprising 
interface means for providing a direct connection to a media gateway con- 
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trol device (40) to enable routing of a set-up call for said conference call 
from said circuit-switched network to said application server (20). 

40. A server device according to any one of claims 31 to 39, further comprising 
means for implementing media gateway controller functions in the same 

5 server device. 

41 . A computer program product comprising code means adapted to produce 
the steps of any one of claims 1 to 10 when loaded into the memory of a 
terminal device (15, 17). 
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Abstract 1 1 Sep. 2003 

The present invention relates to a mechanism for providing an IP-based confer- 
ence call service to a circuit-switched network, such as a GSM network, wherein a 
request for a conference call is forwarded via a data channel or data path to an 
5 application server (20) which provides that conference call service. The application 
server (20) selects a conference routing number and returns the routing number to 
the conference host terminal via the data channel. Using the received conference 
routing number, the conference host terminal (15) can then set up a circuit- 
switched connection as a call leg of the conference call. Thereby, participants in a 
10 circuit-switched network environment can use the enhanced conference service 
provided in IP-based networks. 

[Fig. 1] 
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